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Contributions and correspondence should be sent to: 


Robert Hassinger, Coordinator - 12 Bit SIG 


c/o DECUS MR2-3/E55 ..or.. Liberty Mutual Research Center 
One Iron Way 71 Frankland Road 
Marlboro, MA 01752 Hopkinton, MA 01748 


DECUS/Europe contributions are solicited through: 


Lars Palmer 

DECUS/Europe 12 Bit SIG Newsletter Liaison 
Hassle 

Fack 

S-431 20 MOLNDAL 1 

SWEDEN 


(Please include reference to Newsletter number and page when inquiring about material 
published.) 


NEWSLETTER SUBMISSIONS 


The Newsletter is currently published bi-monthly in the odd months. The deadline for 
each issue is the last Friday of the preceding even numbered month. Submissions are 
accepted at all times and are normally used in the next issue to go to press 
regardless of date of receipt. The deadline for ready-to-use material for the next 
Newsletter is 25-April-80. Material requiring editing/re-typing should be in earlier. 
Ready-to-use material should use an area 7 inches (18 cm) wide by no more than 9 
inches (23 cm) long on each page. It should be single spaced on white bond paper 
whenever possible and must be reasonably clean, legible and sufficiently dark for good 
photographic reproduction. 


Material submitted in machine readable form is particularly desirable because it can 
be edited and incorporated into the newsletter format more easily. Higher quality 
reproduction is also possible this way. Contact the editor (Bob Hassinger) for 
further details on acceptable media and formats if you plan to make a submission in 
machine readable form. 


©1980,DECUS 
It is assumed that all articles submitted to the editor of this newsletter are with the authors’ permission to publish in any DECUS publication. 
The articles are the responsibility of the authors and, therefore, DECUS, Digital Equipment Corporation, and the editor assume no responsi- 
bility or liability for articles or information appearing in the document. 
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SIG COMMITTEES AND WORKING GROUPS 
Steering Committee: 


Robert Hassinger - address above —- (617) 435-3452 


Jim Crapuchettes Lee Nichols 

Menlo Computer Associates, Inc. Ew Ls Dw Pont 

801 E. Charleston Rd. Suite F Experimental Station 
Palo Alto, Calif. 94303 Building 357 

(415) 494-3170 Wilmington, DE 19898 


(302) 772-3839 
Jonathan Lockwood 


Harris Semiconductor Lawrence H. Eisenberg 

PO Box 883 17141 Nance Street 
Melbourne, FL 32901 Encino, California 91316 
(305) 724-7542 M.S. 54-40 (213) 788-0354 


Special Steering Committee Advisors: 
Stan Rabinowitz Tom W. McIntyre 
Micro-8 Working Group and US Symposia Committee Representetive 


Jonathan Lockwood - see above 


RTS-8 Working Group WPS-@ Working Group 
Lee Nichols - see above Steven A. Taylor 

Kubernan 

Cloverdale Executive Building 
COS-310 Working Group 2110 Cloverdale Avenue 
Lawrence H. Eisenberg - see above Winston-Salem, NC 27103 


(919) 725-1915 
Symposium Software Exchange Committee 


Send copies of software you wish to exchange at the next US Symposium to one of the 
following committee members for preparation: 


Earl T. Ellis, Jr. James Coryell 

USCG R & D Center 863 France 

Avery Pt. Simi Valley, CA 93065 
Groton, CT 06340 (805) 526-7478 


(203) 445-8501 Ext. 296 
(FTS) 642-7274 Ext. 296 


DEC WORD PROCESSING UPDATE 


As many of you are aware, DEC has been having trouble with their word processing 
product line recently. Through WPS on the DECstation-78, everyone seemed very happy 
with the products, marketing and service. With the introduction of the 200 series, 
the situation seems to have turned around to where a considerable number of important 
customers are extremely dissatisfied with the product and the product line. 
Apparently the development of the 200 series was done with inadequate resources. In 
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the last several months I have been hearing a great many complaints about how poorly 
the 200s are working and how unresponsive the product line has been to the customers’ 
problems. The kind of unresponsive attitude demonstrated seems to me to be fatal to 
the prospects of a group trying to sell a ready to go, "turn key" level product like 
word processing. 


At the Fall Symposium we saw a glimmer of hope. At least some second level people 
from the product line showed up but they were not prepared to commit to effective 
solutions. Many of those in attendance seemed to feel that the people who were in 
charge and had the authority to make the necessary commitments had ducked the 
Symposium, presumably to avoid the inevitable confrontations with dissatisfied 
customers and to avoid being put on the spot regarding the problems and their 
solutions. This was consistant with the attitude towards non-communication with the 
users perceived prior to the Symposium that led to so much dissatisfaction. (Every 
development project of any size has its problems, the key to keeping them under 
control is honest, responsive communication.) 


Representatives of other product lines who have been dealing with the users through 
DECUS Symposia and Special Interest Groups for any period of time generally find that 
the best, most productive policy is to be open and responsive, even admit to problems 
and honestly talk about what is involved and what the prospects are. It seems very 
clear that the Word Processing product line has yet to learn this lesson. 


Some customers who are in a position to do so, seem to have gone over the heads of the 
product line to very senior DEC management to demand resolution of the situation. The 
indications to date are that the message has gotten through at that level. Top 
management is addressing the resolution of the problems and responding to the 
customers. It is very interesting to note that top management appears to be very 
interested in the the future of Word Processing/Office Automation. It looks as though 
there is an ongoing place in their plans for hardware based on the PDP-8 architecture. 
I think DEC anticipates selling a lot of small, low cost systems in the future. They 
may look rather different from some of the familiar machines we all know and love but 
I suspect they will still do TADs and DCAs. Watch for more on this in the coming 
months. 


It seems to me that what is happening is that the technological imperative of lower 
cost hardware and the needs of the office of the future are going to dominate. DEC 
will meet the challenge in spite of the few short sighted individuals. When Word 
Processing management learns the lessons that many others have learned in the past, we 
will be back on track with good word processing products and happy users. 


RH 
NOTE FROM JIM VAN ZEE 


"Never say there won't be another version of something! After firmly declaring that 
UWF was 'a stable product', I have been enticed to produce 'V4G' by some work on a 
version of FCCAL for the PDP-11 described by Geoffrey Grinton at the last Australian 
DECUS meeting. Grinton added s me elements of ‘structured programming' which looked 
very interesting (see the Proceedings for further details), and while I have not 
followed his scheme exactly because UWF has a number of other features which were in 
conflict with some of the things he did, I have been able to include two major new 
items: relational expressions and the UNTIL command. 
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"Relational expressions let you compare two quantities with the aid of the familiar 
‘relational operators' in FORTRAN. Thus to check if 'A' is larger than 'B', you can 
now write 'IF (A,GT,B)', which, if TRUE, will execute the code following the IF, and 
if FALSE, will take the 'negative if' branch. Grinton's version allowed such commands 
to be written without any line number references at all, using a special statement 
terminator to delimit the 'true' commands from the 'false' ones. My implementation is 
not so fancy, but offers some other advantages. 


"Relational expressions are not confined to IF and ON commands, but may be used in any 
context. They have the value '+1' if TRUE and '-1' if FALSE. Any of six possible 
operators may be used: EQ, NE, LT, LE, GT or GE. The two expressions must be enclosed 
in parentheses and must be separated from the operator by commas (FORTRAN uses 
‘periods’, but FOCAL must use commas). Thus it is now possible to have a command such 
as: TYPE FSQT(<A,GT,0O>*A) which is effectively the same as taking the absolute value 
of the argument. 


"Furthermore, it is possible to write Arithmetic Expressions to produce the result of 
"Logical Operators': 'NOT' is just 'minus', 'XOR' is '-A*B' ('A' and 'B' are 
Relational Expressions), and the 'AND' and 'OR' operators can be written as 
"FSGN(A+B-1)' and 'FSGN(A+B+1)', respectively. It is interesting that the only 
difference between these two is whether one adds or subtracts '1'. For simple 
combinations the 'FSGN' function can often be omitted: 'ON (<FSR() ,EQ,2>4+<X,LT,Y>+1)' 
tests the 'OR' of those two conditions while the same expression with a '-1' would 
produce an 'AND' test. 


"The new UNTIL command combines properties of the IF and FOR commands. The form is: 
'UNTIL (expr); COMMANDS' which will execute all the remaining commands on the line 
-until- the expression being tested becomes -poSitive-. Relational expressions thus 
cause the UNTIL commend to loop until the condition bejng tested is -true-: 'UNTIL 
(DELTA,LT,1E-3); DO 5'. Since the UNTIL command provides only a -testing- function, 
it is necessary that the commands in the loop change the value of the expression - 
otherwise the UNTIL loop will never stop! (This is sometimes convenient: 'U (-1);S 
FMQ(FSR())' will display the switch register in the MQ until interrupted by typing 
CTRL/F.) Alternatively, the expression can involve external events, such as the 
setting of the sense switches or the value of the FTIM function, which will control 
the duration of the loop. An inportant difference between UNTIL loops and FOR loops 
is that if the expression is initially positive the program will immediately skip to 
the next line, thus bypassing the loop commands entirely. NEXT and BREAK can be used 
with UNTIL loops just as they are with FOR loops, and, of course, FOR and UNTIL loops 
can be nested if necessary." 


For more information contact Jim at Lab Data Systems, 10320 Ravenna Ave. NE, Seattle, 
WA 98125 (Phone: 206-522-6950 before 8:30am). Jim indicated that a FPP8A version may 
be available in the near future. 


HINTS AND KINKS FOR THE TU58 


The TU58 ("DECtape II") tape system is starting to become available now. We keep 
hearing that DEC has big plans for it. New computer systems (like the PDP-11/44) are 
supposed to be shipped with a TU-58 standard (the way a floppy drive is part of the 
VAX, etc.). This is supposed to give a standard way of loading diagnostics and to 
distribute machine readable software updates (i.e. "Autopatch"). The DECUS Program 
Library Committee is looking at TU-58 tape as a good media for software exchange. 
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One of the things I like about the TU-58 is the low cost and easy interfacing. The 
usual serial interface version uses a standard serial port such as a KL8JA, etc. The 
unit contains a microprocessor that sends and receives data and control commands in 
the form of normal 8 bit bytes. It looks as though you could very easily make up a 
TU-58 in a portable box and take it from system to system, pluging into a serial port 
on each. The interfacing software should not be too hard to write for almost any 
computer. 


When I finally got a users manual for the TU-58, I found one thing that seems to be a 
problem in the interfacing. The computer initializes or reinitializes the link to the 
TU-58 by sending "Break". This is needed to uniquely get out of any condition that 
the interfacing protacol might get into. The problem is that most of DEC's 12 bit 
system serial interface options (like the KL8JA for example) do not seem to have a way 
to generate a break (i.e., hold the line spacing for considerably more than one 
character time). 


Jonathan Lockwood gave me a good idea on this. In the case of the DECstation, the 
software can change the baud rate of the serial line interfaces. Normally, you will 
connect to the TU-58 with as high a baud rate as possible (the TU-58 will run up to 
38K baud). If the computer resets the rate of its interface to a lower rate, and then 
sends, say, a null, from the point of view of the TU-58 it will look like a break 
because the line will be spacing for longer than a full character time. If anyone 
else has ideas on this problem, particularly for interfaces that do not have 
programmable rates, let me know. 


Also, we understand from a very reliable source (none of us has had a chance to try 
out a TU-58 to verify it) that there is an undocumented feature that is potentially of 
great interest to the 12 bit world. The TU-58 is formatted in 128 byte blocks. 
Normally the builtin controller automatically combines four of these physical blocks 
into one logical block. Normally, you can only address the tape on 512 byte 
boundries. To access the standard interchange format tape, you will have to read 512 
byte blocks with some sort of special interchange program (like PIP10, etc.). This is 
not very attractive for 12 bit systems for non-interchange purposes involving OS/8 
compatible storage where the result is a very unattractive 25% waste of available 
storage. We have been told that the there is a hidden bit in one of the TU-58 
commands that changes the addressing mode to 128 bytes per block so that logical block 
addresses match the physical blocks. With this feature, it should be possable to 
access the entire contents of a tape in terms of 384 byte, OS/8 sized logical blocks. 
As the users begin to have access to TU-58s, I hope they will check this out and let 
us know. 


I hope that if anyone starts to write software for the 12 bit systems to utalize the 
TU-58 that they will consider coordinating their efforts through me and our SIG so 
that we can be aS compatible as possible within the 12 bit world and with DEC's 
efforts in the 16 and 32 bit areas. 


DECUS PROGRAM LIBRARY 
The following programs has been added to the library: 
DECUS 8-916 -— KODER - "KODER, when used with the simple interface described in the 


write-up, will accept characters at the teletype and send them in Morse Code over a 
suitable practice oscillator or radio transmitter. 
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"A line of characters is typed in response to KODER's prompt, a carriage return sends 
the entire line, and then KODER reprompts for more input." 


Paper tape system, 4k memory. Written in PAL-8/PAL-III by Mark Francis of McDonnell 
Douglas Automation Company. Media (price) codes: A2, F5, G7. 


DECUS 8-917 - WPS-8 to COS-310 File Conversion Utility - "WPS-8 to COS-310 Utility 
('WPS>COS') converts WPS-8 structured list files to COS-310 structured data files for 
use in DIBOL-8 programs. The utility permits various types of input (such as 
accounting data, time slips, employee time records, etc.) to be input during regular 
word processing, without the necessity for changing the SYSTEM (requiring word 
processing down time) to input data processing items. Input lists may be stored in 
abbreviation libraries and called up as needed, and entries made in random order. 
Subsequent DIBOL programs can SORT all such files and provide for editing and 


operations not otherwise performed in the word processing mode. 


"The WPS-COS Utility significantly modifies earlier similar utilities by DEC with time 
savings of up to 250% (or more). The operator now is required to provide only NAME OF 
DISKETTE and DOCUMENT NUMBER being transferred. Documentation on source files is 
extensive, and points to the few program lines which may be modified for personalized 
applications. The documentation is supplemented by a README source file and a 
write-up." 


COS-310 all versions, 8k words. Regardless of WPS file length, the WPS diskette must 
be assigned one logical unit containing 41 segments (i.e., the entire diskette). 
Written in DIBOL-8 by Lawrence H. Eisenberg of Encino, CA. Media (price) codes: D3, 
K25. 


DECUS 8-918 - RECA: Regular Expression Compiler/Arithmetic - "REC (for Regular 
Expression Compiler) is a high level language created by H.V. McIntosh as an 
application of machine theory and automata theory. This language has a very simple 
syntax and semantics, and is easy to learn. 


"REC does not have a specific application. It has as many as you like, one of them is 
to solve numerical problems. The REC version which is oriented to handle such matter 
is named REC/ARITHMETIC (RECA). 


"RECA has BASIC and FOCAL facilities but without the respective tedious grammatical 
rules. Due to its easy handling, it is an ideal programming language for beginners 
and very useful aid for experienced people. 


"RECA has been used to solve simple to complex problems on Physics such as, 
Schroedinger equation solution and other quantum-mechanical problems. 


"This version, for the PDP-8 uses 2K memory and all arithmetic operations are carried 
out by DEC-08-YA3A-PB (floating point package, slightly modified) which uses 12 pages 
of memory. It also works with the 4K Disk/DECtape Monitor System allowing users to 
handle disk files. 


"Full documentation about REC and its different versions (applications), including 
RECA, can be obtained from the submitter." 


Written in PALD by Wilfredo Lopez F. and Hector Saldana A. of Instituto Nacional de 
Investigaciones Nucleares, Mexico. Media (price) codes: A2, F7, G32. 
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DECUS 8-919 - BASIC User Defined Functions for the LQP78 - "The user defined functions 
for the LQP78 enables OS/8 BASIC to control the printer like an X-Y plotter. The 
LQP78 is normally used as a letter quality printer. It also has the capability of 
moving the carriage right and left in 1/120 inch increments and moving paper up or 
down in 1/48 inch increments. Therefore, from a machine language level the LQP78 can 


be controlled like an X-Y plotter with acceptable resolution for many applications." 


For OS/8 BASIC V5 (links to BRTS may be different for other versions), standard memory 
requirements. Written in PAL-8 by John Scmidt of Digital Equipment of Canada Ltd., 
Richmond, B.C., Canada. Media (price) codes: D2, K25. 


DECUS 8-920 - GEM: Gordon's Editor and Macro - "GEM is an extensive rewrite of EDIT-8 
and MACRO-8, which combines these two programs in one coherent package. The resulting 
program retains all the normal characteristics of each of its ancestors, as well as at 


the end of pass 1 of the assembly phase. 


"GEM is implemented as a base program and a series of overlays. It may easily have 
other input/output devices added and be reconfigured if necessary. 


"Included is an additional overlay which supports multi-user operation of the Editing 
portion of GEM only - up to five separate users. 


"GEM is fully re-entrant and could be committed to ROM if desired." 


Operating system independent (stand-alone), needs 8k minimum. Written in MACRO-8 by 
G.A. Moyle from the University of New South Wales, Australia. Media (price) codes: 
A3,H30,K25. 


DECUS 8-143 has been withdrawn from the library. 
PT; DEVICE HANDLER 
Jim van Vee sent the following information on a device handler he has: 


"The PT: handler is just like the DEC paper-tape handler for the 'low speed' reader 
(i.e. the reader on an ASR33 Teletype), but with a few enhancements: 


1) Only one entry point (PT:) is used, instead of separate entry points for reading 
(PTR:) and writing (PTP:). This is advantageous due to the limited number of 
handler names permitted by the system. If PT: is called as an input device it 
will use the reader, and if called as an output device it will use the punch. 

The command decoder specification 'PT:<PT:' is the same as the specification 
'PTP:<PTR:' and makes a copy of the input tape (use the '/I' switch with PIP for 
best results when doing this). In order to use the '-P' CCL switch, however, you 
must first .ASSIGN the name 'PTP' (.AS PT PTP); then you can use commands such as 
-COPY file-P. 


As with the standard DEC handler, the PT: handler will print a '™' ('uparrow' or 
‘circumflex') on the terminal when it is called upon to read a tape. This is the 
signal to the user to load a tape in the reader and turn it on. The 
"end-of-tape' is sensed when the reader is turned off, at which point the handler 
inserts a CTRL/Z (ASCII 232) in the file and returns to the calling program. 

Note that NO character checking is performed during a read, so CTRL/Z is a legal 


3) 


"Re: 
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input character which could occur on a binary tape, for instance. Similarly, no 
character checking is performed during output, so when copying a tape (PT:<PT:), 
the CTRL/Z generated by turning off the reader will appear on the output tape 
after the last character read, followed by as many 'nulls' (blank tape) as were 
needed to fill up the buffer. (This could be quite a few if a large buffer were 
being used!) An output tape produced in this way will thus not be an exact 
"hole-for-hole' image of the input tape, but it will be just the same as a tape 
produced using the standard DEC handler. 2) The keyboard is monitored during 
both input and output to see if the user types CTRL/C. This normally causes the 
operation to be aborted with an immediate return to the OS/8 Keyboard Monitor 
(the '.'). However, when the handler is being used with the low-speed reader, 
input from the tape is identical to input from the keyboard, so in this case the 
CTRL/C trap is disabled, allowing this character to be input from the tape. 
Simply turn off the reader if you wish to abort in this special case and delete 
the 'garbage' file (if any) which results from the 'EOT' being sensed. 


A significant advantage of this handler compared to the standard 'LSPT' handler 
is that the Device Code can be easily changed with the SET command. This is 
useful for sending data to a device which 'looks' just like a 'TTY', but has been 
interfaced with a different device code, for example, a small data recorder. In 
another case, one may actually have an old 'TTY' connected up as a ‘lineprinter' 
(using device code 66) and wish to be able to read or punch an occasional paper 
tape. These two requirements were, in fact, the motivation for producing this 
handler. 


The default device codes for the PT: handler are 65 (input) and 66 (output). 
These can be easily changed once the handler is installed in the system by using 
the 'SET PT: DVC XX' command, where 'XX' is the -OUTPUT- device code. The 
handler itself then sets the input device code to one less than output, i.e. if 
output=66, input=65 automatically. Using this method the handler can be easily 
changed for devices having codes 30-77. However codes below 30 (i.e. O4 for the 
standard low-speed punch) cannot be set in this way, but must be patched in 'by 
hand' using the 'SET PT: LOC nnn' command. Two consecutive locations must be 
changed: locations 100 and 101 (easy to remember!). These should be set to 6XX6 
and 6XX1, respectively, where XX is the device code. For example, 'SET PT: LOC 
100=6046' and 'SET PT: LOC 101=6041' will allow this handler to be used with the 
standard low-speed reader/punch. Once set to a value below 30 these instructions 
cannot be changed with the 'SET PT DVC' command, but must again be patched by 
hand as indicated above. This is a limitation of the SET command due to the 
problem of distinguishing user IOTs from field-change and keyboard instructions. 
The keyboard CTRL/C trap is disabled during input when the output device code is 
O4 (see #2 above)." 


PIP BUG 


Jim van Zee forwarded a copy of an SPR he has submitted to DEC on serious problems in 
PIP: 


"Attn: OS/8-OS/78 Maintainers 


Serious problems in PIP (V14A) as distributed with OS/78-V3, the 
OS/8-V3D Device Extension Kit, and the V3D Combined Kit (QF024). 
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"This version has a serious coding error: two routines which are used by the /S and /Z 
options (GETEQ and DVREDE) have been located in a buffer! Thus as soon as the buffer 
is used these routines are destroyed, which soon leads to various sorts of system 
crashes (usually a halt). There are many possible examples, but here are two simple 
cases which DO work correctly with previous versions: 


Ee “i -R PIP (A commonplace example: squish 
*DTA1:<DTAO:/S/O0 one DECtape onto another and 
*DTAO:</Z (halts) then zero the first tape.) 


Ex. 2:3 -R PIP (Another practical example: 
*MERGE.PA<RXAO:A.PA,B.PA,C.PA (merge 3 files, then 
*RXA0:<RXA0:/S/0 (halts) squish the floppy.) 


"The first example uses the buffer (SQBUF1) to hold a copy of the directory; the '/Z' 
option then fails when it tries to use GETEQ and/or DVREDE. The second example uses 
the buffer (ABUF) to repack each line; the attempted squish then fails for the same 
reason. I have developed a rather lengthy patch which fixes this disaster by moving 
these two routines to a different page, in place of the 'MOVE' routine which is no 
longer used in V14A. The ODT-level patch is a little messy because of the need to fit 
things in available 'holes', but at least it can be done! The source-level fix for 
'V15' should be straight-forward. A copy of the patch I have developed is enclosed. 


"A second, and unrelated, problem is that this version cannot be used while the SPOOLR 
is running! The version in OS/78-V2 contained extra startup code for patching certain 
buffer locations so that the vital instructions at locations 1-3 were not destroyed. 
(PIP normally has a buffer starting at location 00000.) For some reason this code was 
omitted in V14A. There should be ample room to include this feature in the next 
release after moving GETEQ and DVREDE as indicated above, but why not just make such 
buffer assignments permanently? An example of a legitimate operation which fails when 
the SPOOLR is running is: 


Ex. 3: ~SQ RXA1:/0 (machine halts) 


Another example involves transfers between SLU2: and SLU3: which must be done with 
PIP. (If you try to use the .COPY command for this you get a message saying: 'USE 
PIP'!) So it is certainly necessary to be able to use PIP while a symbiont is 
running!" 
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3 DATA SYSTEMS, INC. 


6 Pinewood Drive 
Monsey, N. Y. 10952 
(212) 737-3748 


January 8, 1980 


Mr. Robert Rassinger, Coordinator 
12 Bit-SIG 

One Iron Way - DECUS 

Marlboro, Mass 01752 


re: PDP-8 System 
Dear Bob: 


We recently encountered what appears to be a hardware problem on the PDP-8 using 
the LA120 hard copy terminal under both the EIA interfaces and the 20 MA inter- 
face. The problem occurs with both the KL8-JA interface and the DKC8-AA inter- 
face. When printing, the LA120 causes the system to re-boot itself or halt, if 
the auto re-start is in the off position. We've had Digital Field Service at our 
site working on the problem for approximately one month, working three to four 
hours per day. To date, they have not been able to determine any particular 
cause. Similiar problems occur with the LA120 at two of our other sites. 


The Technician from Digital has replaced the power supply of the terminal, the 
interface, logic and power boards, various motors and virtually every part of the 
terminal but the keyboard. The terminal data line was plugged to a second system 
while its power cord was still connected to the first system's power outlet and 
the second system re-booted. Therefore, it is passing through the interface some- 
how to the omnibus and activating the booting sequence. We believe it is causing 
a power low flag to come on and then to drop. At this writing a method has not 
been worked out to resolve this problem. 


The problem occurs at any Baud rate from 600 - 9600 with or without the X ON/X 
OFF option enabled and whether it is hooked up as the system console to a second 
terminal or as a line printer. In addition, the problem only occurs while print- 
ing to the device. If no printing is done, the system performs normally. 


If it could be of help to anyone, our full system configuration is as follows: 


8A425 CPU 32k MOS with a DKC8-AA 

RL8A Disk Controller 

3 RLO1 Disk Drives 

2 KL8-JAs 

LA120-BA with 20 MA Option 

VT1O0-AA with 20 MA Option 

LA8A-PA terminal (connected to the DKC8 Option Board) 
Programmer's console connected to the system. 


Page 1 of 2 


#39 - PAGE 11 


January 8, 1980 
Mr. Robert Hassinger - 


If anyone can be of assistance with the aforegoing, it would be greatly appreciated 
by our company and the local Digital Field Service Technicians (who acknowledge 
that there is a problem but to date, have not been able to localize it). 


Thank you for your courtesy and help. 


Sincerely yours, 


a 


7 <n 7} i : , 
Aaron S. Weg y 


Exec. Vice Presiden 


P.S. The problem usually occurs after about 30 or 40 minutes of continuous 
printing at which time it repeats every 2 to 3 minutes. 
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